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Status of this Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 
Official Protocol Standards" (STD 1) for the standardization state 
and status of this protocol. Distribution of this memo is unlimited. 


Copyright Notice 
Copyright (C) The Internet Society (1998). All Rights Reserved. 
1. Introduction 


This document contains the definitions, originally contained in RFC 
1494, on how to carry CCITT G3Fax in MIME, and how to translate it to 
its X.400 representation. 


NOTE: At the moment, this format does not seem appropriate for a 
"general purpose image format for the Internet", if such a beast can 
exist. It exists only to carry information that is already in G3 Fax 
format, and may be usefully converted to other formats when used in 
specific contexts. 


2. The image/g3fax content-type 
This content-type is defined to carry G3 Facsimile byte streams. 
In general, a G3Fax image contains 3 pieces of information: 

(1) A set of flags indicating the particular coding scheme. 
CCITT Recommendation T.30 defines how the flags are 
transmitted over telephones. In this medium, the flags are 
carried as parameters in the MIME content-type header 
field. 

(2) A structure that divides the bits into pages. CCITT 


recommendation T.4 describes a "return to command mode" 
string; this is used here to indicate page breaks. 
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(3) For each page, a sequence of bits that form the encoding of 
the image. CCITT recommendation T.4 defines the bit image 
format. This is used without change. The highest bit of 
the first byte is the first bit of the T.4 bitstream. 


2.1. G3Fax Parameters 


The following parameters are defined: 


(1) page-length - possible values: A4, B4 and Unlimited 

(2) page-width - possible values: A3, A4, B4 

(3) encoding - possible values: 1-dimensional, 2-dimensional, 
Uncompressed 

(4) resolution - possible values: Fine, Coarse 

(5) DCS - a bit string, represented in Base64. 

(6) pages - an integer, giving the number of pages in the 
document 


If nothing is specified, the default parameter settings are: 


page-length=A4 
page-width=A4 
encoding=1-dimensional 
resolution=Coarse 
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It is possible (but misleading) to view the representation of these 
values as single-bit flags. They correspond to the following bits of 
the T.30 control string and X.400 G3FacsimileParameters: 


Parameter T.30 bit X.400 bit 
page-length=A4 no bit set 
page-length=B4 19 21 
page-length=Unlimited 20 20 
page-width=A4 no bit set 
page-width=A3 18 22 
page-width=B4 dl 23 
encoding=1-dimensional no bit set 
encoding=2-dimensional 16 8 
encoding=Uncompressed 26 30 
resolution=Coarse no bit set 
resolution=Fine 15 9 


The reason for the different bit numbers is that X.400 counts bits in 
an octet from the MSB down to the LSB, while T.30 uses the opposite 
numbering scheme. 


If any bit but these are set in the Device Control String, the DCS 
parameter should be supplied. 


2.2. Content Encoding 


X.400 defines the g3-facsimile data stream as a SEQUENCE of BIT 
STRINGS. Each BIT STRING is a page of facsimile image data, encoded 
as defined by Recommendation T.4. The following content encoding is 
reversible between MIME and X.400 and ensures that page breaks are 
honored in the MIME representation. 


An EOL is defined as a bit sequence of 

000000000001 (eleven zeroes and a one). 
Each page of the message is delimited by a sequence of six (6) EOLs 
that MUST start on a byte boundary. The image bit stream is padded 
with zeroes as needed to achieve this alignment. 
Searching for the boundary is a matter of searching for the byte 


sequence (HEX) 00 10 01 00 10 01 00 10 01, which cannot occur inside 
the image. 
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See Section 7.5 for the algorithm on conversion between this encoding 
and the X.400 encoding. 


The Base64 content-transfer-encoding is appropriate for carrying this 
content-type. 


3. g3-facsimile - image/g3fax 


X.400 Body part: g3-facsimile 
MIME Content-Type: image/g3fax 
Conversion Type: nearly Byte copy 
Comments: 


The Parameters of the X.400 G3Fax body part are mapped to the 
corresponding Parameters on the MIME Image/G3Fax body part and vice 
versa. Note that: 


(1) If fineResolution is not specified, pixels will be twice as 
tall as they are wide 


(2) If any bit not corresponding to a specially named option is 
set in the G3Fax NonBasicParameters, the "DCS" parameter 


must be used. 


(3) Interworking is not guaranteed if any bit apart from those 
specially named are used in the NonBasicParameters 


From X.400 to G3Fax, the body is created in the following way: 

(1) Any trailing EOL markers on each bitstring is removed. The 
bit order is changed to conform to the most common Internet 
encoding (highest bit of first byte = first bit of the 
G3Fax). The bitstring is padded to a byte boundary. 


(2) 6 consecutive EOL markers are appended to each bitstring. 


(3) The padded bitstrings are concatenated together 


An EOL marker is the bit sequence 000000000001 (11 zeroes and a 
one). 


From G3Fax to X.400, the body is created in the following way: 


(1) The body is split into bitstrings at each occurrence of 6 
consecutive EOL markers. Trailing EOLs must NOT be removed, 
since the X.400 Implementor Guide recommends that each page 
should end with 6 consecutive EOLs. (This is a change from 
RFC 1494). 
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4. 


(2) Each bitstring is made into an ASN.1 BITSTRING, reversing 
the order of bits within each byte to conforom to the X.400 
Implementors Guide recommendation for bit order in the 
G3Fax body part. 


(3) The bitstrings are made into an ASN.1 SEQUENCE, which forms 
the body of the G3Fax body part. 


Usability of G3Fax body parts 


This section is not part of the proposed standard, but is intended as 
guidance for people implementing G3Fax handling, so that they know a 
little about what to expect. 


The DCS bitstring is a LONG thing; the T.30 Recommendation (1993) 
gives 67 bits with specific functions, SG8 Report R33 extends this to 
75 bits, and Report R41 (approved in 1995) extends it to 79 bits. 
(For curiosity - bit 68 says that the coding is JPEG; bit 27 is 
"error correcting mode). No sane implementor will send such things 
without being able to negotiate them down if the recipient doesn’t 
support it, but there is no guarantee that messages with such bits 
set in the DCS won’t arrive through X.400. 


The ISO P2 profile from 1995 [PROFILE] says that the profile makes 
support for reception of two-dimensional and fine-resolution 
mandatory if g3-facsimile is supported at all. Research by Andrew 
Gordon of Net-Tel indicates that it is easy for an access unit to 
support fine resolution, unlimited length and B4 length, while 
support for B4 width is nearly impossible, and A3 width is hard. 


Another interesting point is that some fax machines have trouble if 

the scan lines do not contain exactly the declared number of pixels 

on each scan line, so “omitting right-hand white space" is likely to 
give trouble. 


Security Considerations 


There are no known security issues specific to the FAX body part. 
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8. Full Copyright Statement 
Copyright (C) The Internet Society (1998). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
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